AFRL-ir-RS-TR-2004-35 
Final  Technical  Report 
February  2004 


DYNAMO:  DYNAMIC  ASSEMBLY  FROM 
MODELS 


Georgia  Institute  of  Technology 


Sponsored  by 

Defense  Advanced  Research  Projects  Agency 
DARPA  Order  No.  K504 


APPROVED  FOR  PUBLIC  RELEASE;  DISTRIBUTION  UNLIMITED 


The  views  and  conclusions  contained  in  this  document  are  those  of  the  authors  and  should  not  he 
interpreted  as  necessarily  representing  the  official  policies,  either  expressed  or  implied,  of  the 
Defense  Advanced  Research  Projects  Agency  or  the  U.S.  Government. 


AIR  FORCE  RESEARCH  LABORATORY 
INFORMATION  DIRECTORATE 
ROME  RESEARCH  SITE 
ROME,  NEW  YORK 


STINFO  FINAL  REPORT 


This  report  has  been  reviewed  by  the  Air  Force  Research  Laboratory,  Information 
Directorate,  Public  Affairs  Office  (IFOIPA)  and  is  releasable  to  the  National  Technical 
Information  Service  (NTIS).  At  NTIS  it  will  be  releasable  to  the  general  public, 
including  foreign  nations. 


AFRL-IF-RS-TR-2004-35  has  been  reviewed  and  is  approved  for  publication. 


APPROVED:  /s/ 

JAMES  M.  NAGY 
Project  Engineer 


EOR  THE  DIRECTOR:  /s/ 

JAMES  A.  COEEINS,  Acting  Chief 
Information  Technology  Division 
Information  Directorate 


REPORT  DOCUMENTATION  PAGE 

Form  Approved 

0MB  No.  074-0188 

Public  reporting  burden  for  this  coliection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  compieting  and  reviewing  this  coilection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  coliection  of  information,  including 
suggestions  for  reducing  this  burden  to  Washington  Headquarters  Services,  Directorate  for  information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Ariington,  VA  22202-4302, 
and  to  the  Office  of  Management  and  Budget,  Paperwork  Reduction  Project  (0704-0188),  Washington,  DC  20503 

1.  AGENCY  USE  ONLY  (Leave  blank) 

2.  REPORT  DATE 

Feb  04 

3.  REPORT  TYPE  AND  DATES  COVERED 

Final  Jul  00  -  Jul  03 

4.  TITLE  AND  SUBTITLE 

5.  FUNDING  NUMBERS 

DYNAMO:  DYNAMIC  ASSEMBLY  FROM  MODELS 


6.  AUTHOR(S) 

Spencer  Rugaber  and  Kurt  Stirewalt 


C  -  F30602-00-2-0618 
PE  -  62302E 
PR  -  DASA 
TA  -  00 
WU  -  03 


7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

Georgia  Institute  of  Technology 
400  Tenth  Street  N.W. 

Atlanta,  GA  303332-0240 


8.  PERFORMING  ORGANIZATION 
REPORT  NUMBER 


9.  SPONSORING  /  MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 


Defense  Advanced  Research  Projects  Agency 
3701  North  Fairfax  Drive 
Arlington,  VA  22203-1714 


AFRL/IFTB 
525  Brooks  Rd 
Rome,  NY  13441-4505 


10.  SPONSORING  /  MONITORING 
AGENCY  REPORT  NUMBER 

AFRL-IF-RS-TR-2004-35 


11.  SUPPLEMENTARY  NOTES 


AFRL  Project  Engineer:  James  M.  Nagy,  IFTB,  315-330-3173,  naqvi@rl.af.mil 


12a.  DISTRIBUTION  /  AVAILABILITY  STATEMENT 


Approved  for  public  release;  distribution  unlimited. 


12b.  DISTRIBUTION  CODE 


13.  ABSTRACT  (Maximum  200  Words) 

The  DYNAMO  project  is  concerned  with  assembling  high-assurance  systems  from  components,  and,  specifically,  with 
guaranteeing  correct  interaction  of  sets  of  large,  heterogeneous  components.  Several  problems  must  be  overcome  to 
provide  such  guarantees:  1)  dealing  with  the  sheer  complexity  of  the  individual  components  and  their  interoperation; 

2)  maintaining  design  integrity  and  information  hiding  in  the  individual  components;  3)  providing  the  desired  guarantees; 
and  4)  not  compromising  efficiency  while  accomplishing  the  other  goals.  DYNAMO  addresses  these  problems  with 
several  techniques:  1)  a  layered,  implicit  invocation  architecture  limits  complexity  by  reducing  the  quantity  and  nature  of 
allowed  interactions;  2)  a  declarative  specification  mechanism  abstracts  away  low-level  details  such  as  event  dispatch 
and  handling  and  variable  updates;  and  3)  compile  time  component  wrapper  generation  removes  expensive,  inter-layer 
procedure  calls. 


14.  SUBJECT  TERMS 

DASADA,  DYNAMO,  Object  Constraint  Language  (OCL),  high-assurance  software, 
wrapper  generation,  OCL  parser,  invariant  maintenance  architecture,  mode  component 


15.  NUMBER  OF  PAGES 

32 


16.  PRICE  CODE 


17.  SECURITY  CLASSIFICATION 
OF  REPORT 

UNCLASSIFIED 


18.  SECURITY  CLASSIFICATION 
OF  THIS  PAGE 

UNCLASSIFIED 


19.  SECURITY  CLASSIFICATION 
OF  ABSTRACT 

UYNCLASSIFIED 


20.  LIMITATION  OF  ABSTRACT 


UL 


NSN  7540-01-280-5500 


Standard  Form  298  (Rev.  2-89) 

Prescribed  by  ANSI  Std.  Z39-18 
298-102 


Table  of  Contents 


List  of  Figures . ii 

Acknowledgments . iii 

Executive  Summary . 1 

Introduction  and  Problem  Description . 2 

Results . 9 

Future  Work . 20 

Conclusion . 22 

References . 23 

Glossary . 25 


1 


List  of  Figures 


Figure  1  Phase  0  Diagram  for  Text  Browser  Example . 10 

Figure  2  Phase  1  Diagram  for  the  Text  Browser  Example . 1 1 

Figure  3  Phase  2  Diagram  for  the  Text  Browser  Example . 1 1 

Figure  4  DYNAMO  Tools  Architecture . 12 

Figure  5  Encapsulated  Invariant  Maintenance . 14 

Figure  6  Mediated  Invariant  Maintenance . 15 

Figure  7  Distributed  Invariant  Maintenance . 16 

Figure  8  Implementation  of  Encapsulated  Invariant  Maintenance . 17 

Eigure  9  Implementation  of  Mediated  Invariant  Maintenance . 18 

Eigure  10  Implementation  of  Distributed  Invariant  Maintenance . 19 


ii 


Acknowledgments 

The  Pis  on  this  project  wish  to  thank  the  following  student  participants:  Corinne  McNeely, 
Terry  Shikano,  Patrick  Yaner,  and  David  Zook  from  Georgia  Tech  and  Reimer  Behrends  and 
AliReza  Namvar  from  Michigan.  We  also  wish  to  thank  colleague  Laura  Dillon  from  Michigan 
State. 


Executive  Summary 

The  DYNAMO  project  is  concerned  with  the  high-assurance  assembly  of  software  components. 
A  component^  is  a  self-contained  unit  of  computation  capable  of  interacting  with  its  environment 
by  reacting  to  events,  providing  requested  services,  and  managing  its  state.  High-assurance  is  pro¬ 
vided  when  a  set  of  components,  each  of  which  acts  according  to  its  specification,  results  in  a  sys¬ 
tem  that  conforms  to  its  specification.  Specifications  are  expressed  using  the  Object  Constraint 
Language  (OCL)  a  part  of  the  industry-standard  Unified  Modeling  Language  (UML). 

DYNAMO  specifications  describe  invariant  relationships  among  the  states  of  an  assembly’s 
components.  An  invariant  is  a  system  property  expressed  in  terms  of  the  externally  visible  ele¬ 
ments  of  its  components'  states.  When  an  assembly  receives  an  event  from  its  environment,  the 
state  of  one  or  more  components  can  be  altered.  If  that  element  of  state  is  part  of  an  invariant  with 
other  components,  then  it  is  necessary  for  those  other  components  to  be  informed  so  that  they 
might  take  steps  to  reestablish  the  invariant.  This  process  is  called  invariant  maintenance. 

Invariant  maintenance  is  difficult  due  to  the  sheer  complexity  of  the  components  and  their 
interactions.  Moreover,  invariant  maintenance  typically  introduces  costly  run-time  mechanisms 
for  alerting  components  of  changes.  Even  when  invariant  maintenance  is  achieved,  confidence  in 
system  behavior  remains  low  unless  there  is  a  convincing  argument  that  invariants  are  properly 
maintained.  Complex  and  voluminous  code  often  makes  such  an  argument  difficult. 

DYNAMO  addresses  the  invariant  maintenance  problem  with  several  techniques: 

•  Model-based  specification:  Invariants  are  specified  in  dynamo  at  a  high  level  of  abstraction 
by  using  the  industry  standard  Object  Constraint  Language  (OCL)  a  part  of  the  familiar  and 
well-supported  Unified  Modeling  Language  (UML). 

•  Three-phased  design:  dynamo  supports  high  assurance  via  a  design  process  that  converts 
model-based  specifications  into  a  layered,  implicit-invocation  design  guaranteed  to  main¬ 
tain  specified  invariants.  The  design  process  consists  of  three  phases  that  successively 
establish  system  context  within  its  environment,  decompose  the  system  into  components,  and 
layer  the  components  so  as  to  provide  high-assurance  invariant  maintenance. 

•  Wrapper  generation:  Confidence  in  expected  system  behavior  is  provided  by  the  automatic 
generation  of  code  supporting  invariant  maintenance.  Generated  code  wraps  existing  compo¬ 
nents  in  a  way  that  requires  minimal  intrusion  into  the  components,  thereby  reducing  the  risk 
of  introducing  bugs. 

•  Tool  support:  The  dynamo  project  has  developed  and  adapted  a  variety  of  tools  to  support 
the  specification,  design,  implementation  and  validation  of  high- assurance  systems.  Tools 
include  a  graphical  UML  modeling  tool,  an  XML-based  design  extraction  tool,  an  OCL 
parser,  a  code  generator  library,  and  a  model  checker. 

The  current  status  of  the  DYNAMO  project  is  that  the  design  process  is  well  established  and  has 
been  applied  to  a  variety  of  small-scale  problems  including  a  text  browser,  a  mail-spooler,  and  fide 
version-control  (briefcase)  mechanism.  The  invariant  maintenance  architecture,  including  a  num¬ 
ber  of  variants  is  well-defined.  And  the  tools  exist  in  prototype  form  at  various  levels  of  maturity. 
Finally,  a  variety  of  interesting  follow-up  questions  have  been  collected  for  future  work. 


1.  Terms  in  italics  are  defined  in  the  glossary  at  the  end  of  this  report. 
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Introduction  and  Problem  Description 

Software  components  are  units  of  computation.  They  may  exist  in  libraries  or  be  specially 
constructed.  Components  can  be  assembled  into  systems.  However,  there  is  no  guarantee  that 
even  correct  components,  when  combined,  result  in  correct  systems.  Invariants  are  desirable  sys¬ 
tem  properties.  As  a  system  executes  and  its  state  changes,  the  system  must  react  to  reestablish  its 
invariants.  This  process  is  called  invariant  maintenance.  A  change  of  state  may  invalidate  one  or 
more  invariants.  For  each  such  invariant,  corrective  actions  must  be  located  and  verified.  Unfortu¬ 
nately,  this  approach  is  error  prone  and  expensive. 

Invariant  maintenance  is  difficult  due  to  the  sheer  complexity  of  the  components  themselves 
and  their  interactions  with  each  other.  In  addition  to  guaranteeing  that  system  invariants  hold,  a 
solution  to  the  invariant  maintenance  problem  should  satisfy  the  following  additional  properties. 
First,  it  must  refrain,  to  the  extent  possible,  from  intruding  into  the  components  themselves.  This 
property,  sometimes  called  transparency,  has  several  advantages.  It  separates  reasoning  about 
overall  system  properties  from  consideration  of  the  individual  components.  Also,  it  reduces  the 
need  to  modify  the  code  of  the  components,  thereby  lessening  the  risk  of  introducing  bugs. 

The  second  property  is  flexibility.  There  are  a  variety  of  architectural  mechanisms  that  support 
invariant  maintenance.  Flexibility  enables  the  architectural  approach  to  be  selected  by  the 
designer  based  on  other  desirable  system  properties.  Moreover,  flexibility  supports  reuse, 
enabling  components  to  be  packaged  in  various  ways. 

The  third  property  is  low  overhead.  In  particular,  it  should  be  the  goal  of  any  invariant  mainte¬ 
nance  mechanism  to  cause  no  additional  run-time  costs  over  an  ad  hoc  implementation.  As  a  gen¬ 
eral  rule,  the  more  encapsulated  and  self-contained  components  are,  the  more  complex  is  the 
collaboration  mechanism  required  to  support  them.  With  complexity  comes  run-time  overhead.  A 
low-overhead  solution  supports  collaboration  without  any  additional  run-time  cost. 

The  fourth  property  is  intentionality.  That  is,  in  order  to  reason  about  system  behavior,  it 
should  be  possible  to  relate  the  behavioral  specification  of  an  invariant  to  its  implementation  in  a 
direct  way.  In  particular,  each  invariant  should  be  traceable  to  the  code  mechanism  responsible  for 
maintaining  it.  Intentionality  also  supports  maintainability — changes  to  system  requirements 
often  mean  changes  to  the  system’s  invariants.  Intentionally  implemented  invariants  are  easier  to 
alter. 

The  final  property  is  abstraction.  Confidence  in  system  behavior  is  reduced  when  code  must 
be  examined  to  determine  the  effects  of  intricate  combinations  of  events.  Such  efforts  are  labor 
intensive  and  error  prone.  DYNAMO  uses  the  Object  Constraint  Language  (OCL)  [15]  to  specify 
system  invariants  at  a  high  level  of  abstraction.  Wrapper  code  is  generated  to  ensure  that  invari¬ 
ants  are  appropriately  updated. 

The  remainder  of  this  section  describes  the  assumptions  DYNAMO  makes  about  the  problem 
space  and  work  done  by  others  that  relates  to  the  component  assembly  problem. 


2 


Assumptions 

DYNAMO  is  concerned  with  the  high-assuranee  assembly  of  eomponents.  As  a  researeh 
projeet,  we  made  several  assumptions  that  limit  the  seope  of  the  problems  that  we  addressed. 

•  First  of  all,  we  are  eoneerned  with  the  assembly  of  interaetive  systems.  Interaetive  systems  are 
eharaeterized  by  user-generated  stimuli  that  produee  visible  responses.  The  eomplexity  of 
sueh  systems  derives  from  the  extensive  state  spaees  that  arise.  We  ehose  this  area  beeause  of 
our  experienee  with  the  MASTERMIND  projeet  in  whieh  we  also  used  model-based  eode 
generation  [22].  Interaetive  systems  should  be  eontrasted  with  data- intensive  systems  where 
the  bulk  of  the  eomplexity  eoneerns  the  manipulation  of  fairly  regular  data.  Although  we  did 
not  experiment  in  this  area,  we  believe  that  the  DYNAMO  approaeh  eould  also  be  applied  to 
reaetive  systems  in  whieh  stimuli  arise  from  sensors  rather  than  users. 

•  DYNAMO  is  eoneerned  with  the  assembly  of  systems  with  guaranteed  exeeution  properties. 
The  primary  type  of  property  we  investigated  was  behavioral  properties.  Sueh  properties  eon- 
eern  eorreet  exeeution;  that  is,  exeeution  that  produees  expeeted  output.  We  did  some  investi¬ 
gation  of  synehronization  properties  as  well.  Synehronization  properties  indieate  how 
eomponents  eollaborate  to  produee  results.  We  did  not  explore  quality-of-serviee  properties. 

•  The  applieations  that  we  looked  at  were  primarily  single  threaded.  That  is,  eontrol  was 
sequential  within  a  single  address  spaee.  We  did  one  experiment  with  single  proeess,  multi¬ 
threaded  applieations.  We  did  not  look  at  multi-proeess  applieations. 

•  The  design  seenario  we  addressed  is  system  assembly  from  eomponents.  The  eomponents 
may  exist  in  a  library  or  they  may  be  built  from  serateh.  We  are  not  eoneerned  with  monolithie 
systems. 

•  Finally,  we  have  eoneentrated  on  systems  written  in  the  C++  programming  language.  C++ 
features  a  powerful  generie  faeility  (ealled  templates)  that  supports  metaprogramming  and 
effieient  eompilation,  two  features  we  wanted  to  exploit.  We  believe  that  dynamo’s  eoneep- 
tual  eontributions  eould  be  applied  to  any  language  with  these  features. 

Related  Work 

Context.  There  are  a  variety  of  design  strategies  for  maintaining  invariants  among  an  assembly  of 
eomponents.  At  one  extreme,  an  invariant  ean  be  implemented  as  an  explieit  integration  eompo- 
nent,  distinet  from  the  eomponents  it  integrates  (hereafter  referred  to  as  integrands).  Under  this 
approaeh,  the  integration  eomponent  might  be  a  peer  of  its  integrands,  as  is  the  ease  with  media- 
tors[23],  or  it  might  encapsulate  its  integrands,  as  with  GenVoea  layers  [2]  and  faeades  and  adapt¬ 
ers  [8].  Some  designs  even  employ  a  hybrid  of  these  approaehes.  For  example,  Java  AWT 
programmers  define  eontainers,  whieh  (like  layers)  eneapsulate  GUI  eomponents  but  whieh  (like 
mediators)  listen  for  events  from  these  eomponents  [1 1].  At  the  other  extreme,  an  invariant  ean  be 
implemented  as  a  collaboration  [24]  [17],  whieh  distribute  the  responsibilities  for  maintaining  the 
invariants  among  the  integrands.  The  ehoiee  of  integration  strategy  is  subjeet  to  numerous  trade¬ 
offs.  If  we  ehoose  to  use  an  integration  eomponent,  eneapsulation  ean  usually  be  implemented 
more  effieiently.  Integration  eomponents  have  the  advantage  of  not  requiring  integrands  to  be 
modified  with  invariant-speeifie  eode;  however,  eollaborations,  by  virtue  of  being  within  the  inte¬ 
grands,  ean  use  knowledge  of  an  integrand's  internal  state  to  implement  a  more  effieient  update 
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protocol.  These  trade-offs  can  only  be  assessed  once  the  invariants  are  known,  i.e.,  at  assembly 
time. 

In  praetiee,  it  is  diffieult  to  exploit  this  trade-off  at  assembly  time  beeause  integration  strate¬ 
gies  largely  depend  upon  the  mechanisms  that  integrand  components  use  to  communicate  with 
other  components  in  the  assembly.  The  collaboration  approach  uses  explicit  invocation,  whieh  (in 
an  00  implementation)  requires  an  integrand  to  store  a  reference  to  the  other  integrands  and  to 
directly  invoke  operations  through  these  references.  By  contrast,  the  mediator  approaeh  relies  on 
implicit  invocation,  whieh  requires  the  ehanged  component  to  announee  an  event  whenever  its 
state  ehanges  in  a  way  that  might  trigger  the  reestablishment  of  an  (as  yet  unknown)  invariant. 
Finally,  under  encapsulation,  an  integrand  should  not  initiate  eommunication  with  other  compo¬ 
nents  at  all!  The  key  problem  then  is  how  to  design  components  so  that  the  choice  of  mechanism 
for  communicating  with  other  eomponents  can  be  delayed  until  assembly  time.  This  problem, 
whieh  is  also  called  the  flexible  packaging  problem  [6]  requires  a  two-fold  solution.  First,  a  com¬ 
ponent  must  be  designed  to  communicate  with  its  environment  using  a  meehanism  that  is  more 
abstraet  than  the  traditional  procedure  call.  Second,  a  component  must  be  packaged  prior  to  inser¬ 
tion  into  an  assembly.  Packaging  involves  replaeing  the  abstract  communication  primitives  in  a 
component's  source  code  with  actual  code  that  implements  these  primitives. 

Beugnard  et  al,  Beugnard  et  al.  [4]  are  coneerned  with  high  assuranee  component  interaetions. 
Component  interactions  are  deseribed  by  eontracts  clearly  specifying  expected  interactions.  Of 
particular  interest  to  the  DYNAMO  projeet  was  the  authors’  breakdown  of  contracts  into  four  cate¬ 
gories. 

•  Basic  (or  syntactic)  contracts  provide  names  for  operations,  parameters,  and  exceptions. 

Basie  contraets  are  what  are  specified  by  interface  description  languages,  such  as  IDL  [12],  a 
part  of  CORBA. 

•  Behavioral  contracts  assign  responsibilities  to  components.  Behavioral  eontracts  are  what 
are  normally  speeified  by  pre  and  post  conditions  expressed  in  predicate  logic. 

•  Synchronization  contracts  describe  allowable  eoordination  policies  between  components. 

Path  expressions  [5]  are  a  common  notation  for  expressing  synehronization  contracts. 

•  Quality  of  service  contracts  describe  how  non-functional  requirements,  sueh  as  resource 
eonsumption  and  performance  are  handled  by  a  set  of  eomponents. 

Most  of  the  DYNAMO  work  has  been  eoneemed  with  behavioral  contracts.  We  have  used  the 
Object  Constraint  Language  [15] [25]  (an  extension  to  UML)  to  express  these  contracts.  We  have 
also  done  some  work  investigating  synchronization  contracts.  For  this  we  have  developed  a  pow¬ 
erful  model  of  synchronization  contracts  called  the  Universe  Model  [3].  We  have  also  used  Calculus 
of  Communicating  Systems  (CCS)  [14],  Milner’s  notation  for  speeifying  intercomponent 
synchronization  behaviors  to  formalize  our  approaches  to  invariant  maintenanee. 

Shaw  and  Garlan,  Shaw  and  Garlan,  in  their  book  on  software  arehitecture  [21]  describe  a 
design  space  for  implementations  of  implicit  invocation  mechanisms.  Implicit  invocation  pro¬ 
vides  one  solution  to  the  invariant  maintenanee  problem  in  which  components  whose  status 
changes  notify  dependent  components  which  have  expressed  their  interest.  The  notifying  compo- 
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nent  is  not  explicitly  aware  of  the  identity  of  the  notified  component.  This  design  space  is  also  dis¬ 
cussed  in  the  article  [9].  Among  the  factors  the  Shaw  and  Garlan  consider  are  the  following. 

1.  Fixed  or  dynamic  vocabulary  for  events:  Whether  the  set  of  notification  events  is  fixed  in 
advance.  For  DYNAMO,  the  set  of  events  is  determined  by  the  set  of  status  variables,  which  is 
determined  for  the  assembly  specification  at  compile  time. 

2.  Built  in  or  user  defined:  Whether  the  set  of  events  is  fixed  by  the  implementation  or  user 
defined.  For  dynamo,  the  set  of  events  is  fixed  by  the  set  of  status  variable  being  monitored. 
Changes  to  the  status  variables  trigger  a  notification  event  to  dependent  components. 

3.  Explicitly  declared  or  not:  Whether  the  set  of  events  must  be  explicitly  declared  or  is 
dynamically  determined.  For  DYNAMO,  the  set  of  events  is  inferred,  at  compile  time,  from  the 
set  of  status  variables  being  monitored. 

4.  Central  or  distributed  declaration:  Whether  the  event  declarations  are  collected  in  one 
place  or  distributed  throughout  the  assembly.  From  the  point  of  view  of  the  designer,  events 
are  associated  with  status  variables,  and  are  therefore  distributed  throughout  the  assembly. 

5.  Parameters:  Events  are  atomic  notifications,  but  it  is  often  useful  to  supply  values  with 
events  as  parameters.  For  dynamo,  event  parameters  may  be  requested  from  notifying  com¬ 
ponents  via  service  requests  (method  calls). 

6.  Registration  required:  Whether  or  not  a  priori  event  registration  is  required.  For  dynamo, 
the  set  of  events  to  be  handled  is  collected  from  the  specification  at  compile  time,  as  are  the 
sending  (independent)  and  receiving  (dependent)  components.  Registration  is  effected  by  the 
dependent  component  providing  a  notification  method  to  be  invoked  by  the  independent  com¬ 
ponent  when  a  status  change  occurs. 

7.  Translation  of  event  parameter  to  method  parameter:  Most  programming  languages  do 
not  have  an  event  primitive.  So  event  notifications  must  be  translated  into  method  calls.  More¬ 
over,  event  parameters  must  be  made  available  in  the  method  call.  For  DYNAMO,  this  is  done  at 
compile  time. 

8.  Announcement  mechanism:  How  are  event  notifications  implemented?  For  dynamo,  each 
notifying  component  aggregates  a  set  of  status  variables,  the  values  of  which  other  component 
depend  on.  For  each  status  variable,  a  list  of  notification  methods  in  maintained.  Changes  in 
the  values  of  status  variables,  cause  these  methods  to  be  invoked,  thereby  notifying  dependent 
components. 

9.  Component  implementation:  What  programming  language  element  is  used  to  implement  a 
component?  For  DYNAMO,  a  class  is  used  to  implement  a  component.  However,  a  collection  of 
components  that  reside  in  the  same  layer  in  the  architecture  can  be  implemented  as  nested 
classes  within  a  master  class  for  that  layer. 

10.  Concurrency:  Whether  components  and  events  are  treated  concurrently  or  in  a  single  thread. 
Most  of  the  DYNAMO  work  has  been  concerned  with  a  single  thread  of  execution.  However, 
we  have  conducted  some  experiments  in  which  multiple  threads  in  a  single  process  were  used. 

1 1 .  Delivery  policy:  Under  what  circumstances  and  in  what  order  are  dependents  notified?  For 
DYNAMO,  all  dependents  are  notified;  the  order  is  fixed  at  compile  time.  Shaw  and  Garlan  call 
this  full  delivery. 

Dingel,  Garlan,  Jha,  and  Notkin.  Components  in  dynamo  assemblies  inform  each  other  of 

state  changes  using  implicit  invocation.  Implicit  invocation  is  an  architectural  style  in  which  state 
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changes  in  one  component  are  announeed  to  other,  dependent  eomponents,  implieitly.  That  is,  the 
announcing  component  is  not  aware  of  who  it  is  notifying.  Dingel  et  al.  have  provided  a  formal¬ 
ization  of  this  proeess  using  process  algebra  and  traee  semanties  [7].  Their  approaeh  is  eomposi- 
tional — it  supports  reasoning  about  eomposed  systems  by  eombing  the  reasoning  about  the 
eomponents.  Although  DYNAMO  is  primarily  eoncemed  with  implementation  approaehes  for 
implieit  invoeation  systems,  we  have  experimented  with  formalization,  using  Milner’s  Calculus 
for  Communicating  Systems  [14]. 

Riehle.  DYNAMO  uses  C++  templates  to  implement  implieit  invoeation.  Riehle  has  also  designed 
a  C++ -based  template  solution  to  this  problem  [18].  His  approaeh  is  called  the  Event  Notification 
Pattern,  related  to  the  Observer  design  pattern  in  the  design  patterns  book  [8].  In  partieular,  Rie¬ 
hle  makes  the  same,  asymmetrie  design  choiee  as  DYNAMO,  supporting  implicit  notifications  from 
lower-layer  eomponents  to  upper-layer  components,  but  requiring  notifications  in  the  other  diree- 
tion  to  be  explicit.  One  major  differenee  between  Riehle ’s  approaeh  and  that  of  dynamo  is  that 
with  the  former,  components  must  explicitly  indicate  relevant  state  changes,  whereas,  with 
DYNAMO,  state  changes  are  automatically  detected  and  eommunicated. 

VanHilst  and  Notkin.  A  collaboration  is  a  protoeol  of  interaction  among  multiple  objeets  (called 
roles)  to  aehieve  some  purpose  or  goal  or  to  implement  some  invariant  [24].  Here,  a  role  is  not  an 
aetual  objeet,  but  rather  a  fragment  that  eomprises  the  subset  of  an  aetual  object’s  characteristics 
that  are  required  for  the  object  to  participate  in  a  particular  collaboration  [17].  Moreover,  a  role 
might  be  abstract,  which  is  to  say  that  it  merely  deelares  some  operations  without  providing  meth¬ 
ods  to  implement  them.  In  faet,  the  most  reusable  collaborations  are  those  for  whieh  one  or  more 
of  their  roles  is  abstraet.  We  ean  think  of  a  collaboration  as  a  collection  of  roles  that  interact 
according  to  a  protocol  of  message  exehange,  and  we  ean  visualize  this  behavior  using  a  UML 
sequenee  diagram,  eaeh  of  whose  columns  is  labeled  by  a  role. 

Beeause  roles  correspond  to  fragments  rather  than  aetual  objeets,  role  types  are  diffieult  to 
express  as  first-elass  entities  in  many  programming  languages.  VanHilst  and  Notkin  [24]  describe 
how  to  represent  roles  in  C++  using  mixin  classes,  which  are  elass  templates  in  whieh  the  tem¬ 
plate  parameter  is  used  to  define  the  base  elass  from  whieh  the  (instantiated)  mixin  class  derives. 
By  defining  roles  in  this  manner,  a  designer  ean  extend  a  class  to  play  a  new  role  by  instantiating 
the  mixin  elass  that  implements  the  role  with  the  elass  to  be  extended. 

For  example,  suppose  we  have  a  class  C  that  we  want  to  adapt  to  play  role  (R^)  in  a  new  col¬ 
laboration.  If  roleR]^  is  the  mixin  elass  that  implements  R^,  then  we  can  adapt  C  to  play  this  role 
by  defining  a  new  elass: 

C'=  roleRl<C> 

In  addition,  if  we  want  C  to  play  roles  R2  and  R3,  we  would  deelare  C'  as  follows: 

C'  =  roleR3<  roleR2<  roleRl<  C  >  >  > 

In  faet,  using  this  teehnique,  one  can  essentially  derive  a  eustom  elass  just  by  identifying  the  roles 
its  objects  will  need  to  play  in  various  eollaborations. 
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DYNAMO  is  concerned  with  the  assembly  of  systems  from  interactive  components  and  deelar- 
ative  specifications  of  assembly  guarantees,  whieh  govern  component  interaction.  Ultimately, 
these  declarative  speeifications  must  be  translated  to  code  that  interfaees  with  the  eomponents 
being  integrated.  Beeause  an  assembly  guarantee  is  an  invariant,  it  can  be  thought  of  as  a  collabo¬ 
ration,  each  role  of  whieh  is  played  by  one  or  more  of  the  eomponents  being  assembled.  We  have 
thus  explored  how  to  implement  assembly  by  generating  mixin  classes  for  eaeh  role  in  the  collab¬ 
oration  denoted  by  an  invariant  and  then  extending  each  component  to  play  the  appropriate  role 
using  mixin-class  instantiation. 

Batory  and  Smaragdakis.  Mixin  elasses  allow  the  explicit  definition  of  roles  in  languages  that 
support  parameterized  inheritance.  Smaragdakis  and  Batory  [20]  extended  this  idea  to  represent 
eollaborations  using  a  strueture  called  a  mixin  layer,  which  defines  a  collaboration  to  be  a  tem¬ 
plate  class  with  one  or  more  nested  elasses,  each  of  which  is  a  mixin  class  that  defines  a  different 
role  in  the  eollaboration.  Unlike  mixin  elasses,  the  nested  elasses  in  a  mixin  layer  do  not  assign  a 
new  name  to  the  role  being  defined,  but  instead  refer  to  the  elass  that  is  being  refined  to  play  the 
new  role.  A  mixin  layer  has  the  following  form  (in  C++): 

template  <typename  PARENT>  { 

class  CollaborationCl  :  public  PARENT 

class  A  :  public  typename  PARENT: :A  { 

}  ; 

class  B  :  public  typename  PARENT: :B  { 

}; 


} 

Notiee  that  eaeh  nested  elass  (e.g.,  CollaborationCl :  :  A)  refines  a  given  class  (e.g..  A) 
to  play  a  role  in  Cl.  Using  mixin  layers,  one  can  synthesize  a  eollection  of  classes  by  composing 
the  collaborations  in  which  the  objeets  of  those  classes  will  play  a  role. 

Mixin  layers  were  originally  developed  to  implement  GenVoea  layers  and  layered  composi¬ 
tion  without  requiring  the  development  of  a  program  generator.  In  the  original  GenVoea  paper  [2], 
a  eomponent  is  defined  to  be  a  highly-eohesive  eolleetion  of  elasses.  Layered  eomposition  then 
eauses  the  simultaneous  refinement  of  multiple  elasses.  In  dynamo,  we  use  mixin  layers  and  lay¬ 
ered  eomposition  as  a  means  to  represent  a  speeially  designed  component  ealled  a  mode  eompo¬ 
nent,  whieh  is  like  GenVoea  layers  that  also  announce  events.  Most  assembly  invariants  can  be 
implemented  direetly  using  one  or  more  mixin  layers,  whieh  are  then  used  to  simultaneously 
refine  a  eollection  of  components  to  play  roles  in  the  assembly. 

Sullivan  and  Notkin,  A  mediator  is  a  software  component  that  reifies  integration  relationships 
into  a  component  that  is  separate  from  the  eomponents  being  integrated  [23].  Communication 
between  a  mediator  and  its  integrands  is  asymmetrie  in  that  integrands  communicate  with  the 
mediator  indireetly,  using  implieit  invoeation,  whereas  the  mediator  eommunieates  direetly  with 
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integrands  using  explicit  invocation.  This  asymmetry  is  motivated  by  the  desire  to  maintain  com¬ 
ponent  independence  in  order  to  simplify  evolution.  Consequently,  each  integrand  must  announce 
an  event  whenever  any  potentially  important  change  in  state  occurs.  A  mediator  integrates  a  col¬ 
lection  of  integrands  by  registering  for  events  in  each  integrand  and  then,  upon  receiving  events, 
alerting  dependent  integrands  to  update  their  state  accordingly.  Integration  via  mediators  is  the 
most  general  and  most  flexible  strategy  for  component  assembly;  however,  this  generality  and 
flexibility  is  achieved  via  a  heavy  use  of  indirection,  which  may  incur  unacceptable  performance 
penalties  when  the  technique  is  used  to  integrate  more  fine  grained  components.  In  DYNAMO,  we 
use  mediators  to  implement  a  system  of  assembly  invariants  that  incurs  a  dependency  cycle,  and 
we  use  them  in  conjunction  with  encapsulation  to  construct  mode  components. 

De  Line.  A  major  inhibitor  to  the  reusability  of  software  components  concerns  the  communica¬ 
tion  mechanisms  a  component  uses  to  interact  with  its  dependents.  Suppose,  for  example,  that 
component  uses  a  service  of  another  component  C2.  If  these  components  are  to  reside  in  the 
same  address  space,  then  Cl  will  communicate  with  C2  using  a  method  call;  whereas  if  they 
reside  in  different  address  spaces,  must  use  a  remote  procedure  call.  Unfortunately,  in  most 
programming  languages,  the  choice  of  communication  mechanism  is  bound  at  component  devel¬ 
opment  time,  when  in  fact  we  would  often  prefer  to  defer  the  decision  to  assembly  time.  Flexible 
packaging  is  concerned  with  how  to  design  software  so  that  the  choice  of  communication  mecha¬ 
nism  can  be  delayed  until  assembly  time.  DeLine  proposes  a  solution  in  which  components  com¬ 
municate  indirectly  using  channels  via  Linda-like  [10]  coordination  primitives  [6].  In  the  Ciao 
integration  language,  channel  communication  can  be  replaced  with  procedure  calls,  remote-proce¬ 
dure  calls,  and  relational-database  queries,  thus  allowing  the  packaging  decisions  to  be  deferred  to 
assembly  time.  DYNAMO  uses  a  more  restricted  form  of  flexible  packaging,  based  on  C++  tem¬ 
plate  instantiation,  which  allows  the  choice  of  integration  strategy  to  be  deferred  to  assembly 
time. 


Results 


Model-based  specification 

DYNAMO  supports  model-based  specification  of  component  assemblies.  What  this  means  is 
that  a  designer  specifies  an  assembly  in  a  high-level,  declarative  notation  rather  than  operationally 
in  a  programming  language.  The  notation  we  have  used  is  UML  (the  Unified  Modeling  Lan¬ 
guage)  including  the  Object  Constraint  Language  (OCL).  In  particular,  we  have  interpreted  UML 

class  model  constructs  in  terms  of  the  vocabu¬ 
lary  of  software  architecture.  The  interpretation 
Table  1:  dynamo  UML  Interpretation  jg  presented  in  Table  1.  Annotations  to  the  class 

model,  in  the  form  of  OCL  constraints,  provide 
semantics.  In  particular,  external  system  events 
(stimuli)  are  ultimately  modeled  as  methods  in  a 
component.  OCL  pre  and  post  condition  con¬ 
straints  specify  the  effect  of  an  event  on  the  sys¬ 
tem.  Invariants,  initially  indicated  with  natural 
language  annotations,  are  first  translated  by  the 
designer  into  OCL  associations.  As  the  architec¬ 
ture  is  refined,  associations  are  subsumed  by 
dynamo’s  layered  architecture.  At  this  point,  the 
constraints  are  assigned  to  the  component 
responsible  for  maintaining  them. 


There  are  several  benefits  that  derive  from  using  a  declarative  notation.  Because  OCL  is  high- 
level  and  declarative,  designers  can  concentrate  on  system  properties  rather  than  worrying  about 
details.  Because  it  is  abstract,  it  is  more  concise  than  code,  reducing  the  maintenance  burden. 
Because  it  is  declarative,  error-prone  procedural  details  are  elided.  Finally,  because  OCL  is  for¬ 
mally  defined,  it  supports  reasoning.  That  is,  OCL  constraints  can  be  used  to  check  system  prop¬ 
erties  using  various  existing  tools. 

Three-phased  design  method 

The  DYNAMO  design  method^  starts  with  a  declarative  model  of  an  assembly  expressed  as  an 
annotated  UML  class  diagram  using  a  graphical  CASE  tool.  The  diagram  is  refined,  first  into 
loosely  coupled  components  that  are  then  organized  into  a  layered  architecture.  From  the  resulting 
UML  model,  C++  wrapper  classes  can  be  generated  that  assemble  the  components.  To  support 
elficiency  and  reuse,  components  are  assembled  using  a  layered,  implicit-invocation  architecture 
called  a  mode-component  architecture.  A  mode  component  is  a  specialized  component  that  alerts 
its  clients  when  its  state  changes.  Additionally,  the  correctness  of  these  generated  assemblies  can 
be  verified  either  statically,  using  tools  such  as  theorem  provers  or  model  checkers,  or  dynami¬ 
cally,  by  run-time  assertion  checking. 


UML 

Concept 

DYNAMO 

Interpretation 

System 

Assembly 

Package 

Layer 

Class 

Component 

Attribute 

Percept 

Association 

Invariant 

Dependency 

Event 

1.  Details  of  the  dynamo  design  method  can  be  found  in  reference  [13]. 
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User 


{The  resizeWindow  event 
changes  the  height  of 
viewport} 


resizeWindow(newSize :  int) 

_ I _ 

moveHandle(newPosition  :  int) 


(The  moveHandle  event  l\ 
changes  the  position 
of  the  handle  in  the 
scrollbar  tray} 

TextBrowser 


+height :  int 

+viewContents  :  sequence(line)|" 
\+handleSize  :  float 
+handlePosition  :  int 


Document 


l+contents :  sequence(line) 


{The  viewport  presents  the 
maximum  consecutive 
subsequence  of  whole  lines 
from  the  document  that  fit) 


(The  position  of  the  top  of  the 
scrollbar  handle  with  respect 
to  the  scrollbar  tray  reflects 
the  position  in  the  document 
of  the  top  line  currently  visible 
in  the  viewport} 


(The  size  of  the  scrollbar  handle 
with  respect  to  the  size  of  the 
scrollbar  tray  indicates  the 
portion  of  the  document's  lines 
visible  in  the  viewport} 


Figure  1:  Phase  0  Diagram  for  Text  Browser  Example 

The  DYNAMO  design  method  eomprises  three  phases  that  refine  a  eoneeptual  model  of  a  pro¬ 
posed  assembly  into  interrelated  eomponents  organized  as  layered  mode  eomponents.  In  Phase  0, 
the  environment  in  whieh  the  assembly  exeeutes  is  deseribed  in  terms  of  external  aetors,  the 
assembly  itself,  the  eommunieation  among  them,  and  the  behavioral  properties  (invariants)  that 
the  assembly  must  guarantee.  Phase  1  asks  the  designer  to  partition  the  assembly  into  its  eonstitu- 
ent  components  and  their  relationships,  assigning  responsibility  for  external  actions  and  invariant- 
maintenance  to  the  components  appropriately.  Finally,  Phase  2  asks  the  designer  to  layer  the  con¬ 
stituents  as  mode  components,  where  lower-level  components  communicate  status  changes 
upward,  and  higher-level  components  make  specific  service  requests  of  lower-level  components. 
Phase  0,  1  and  2  diagrams  for  a  simple  text  browser  assembly  are  presented  in,  respectively.  Fig¬ 
ure  1,  Figure  2,  and  Figure  3. 

In  Figure  I,  the  assembly  is  denoted  by  the  TextBrowser  icon.  Two  other  actors  comprise 
its  environment — the  user  and  the  document  to  be  viewed.  User  interactions  are  denoted  with 
dependency  arrows,  and  guarantees  are  provided  within  annotation  icons. 
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Figure  2:  Phase  1  Diagram  for  the  Text  Browser  Example 


Figure  3:  Phase  2  Diagram  for  the  Text  Browser  Example 
In  Eigure  2,  the  TextBrowser  has  been  decomposed  into  three  components:  a  viewport,  a 
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scrollbar  and  a  file  manager.  Three  assoeiations  have  been  included  to  indieate  the  eollaborations 
required  to  enforee  the  TextBrowser’s  guarantees.  The  assoeiations  have  been  annotated  with 
OCL  eonstraints  denoting  the  invariants  the  assembly  must  maintain.  The  two  user  events  have 
been  delegated  to  eomponents  as  have  the  four  assembly  percepts. 

Figure  3  presents  the  layered,  implieit-invoeation  arehiteeture  used  to  effect  invariant  mainte¬ 
nance.  The  three  eomponents  have  been  organized  into  a  stack,  and  the  OCL  eonstraints  have 
been  assigned  to  the  respeetive  dependent  attributes.  Ultimately,  the  eomponents  will  be  realized 
as  wrapped  and  nested  template  elasses. 


Tool  support 

A  variety  of  prototype  tools  were  built  or  adapted  to  support  the  investigation  into  invariant 
maintenanee.  The  DYNAMO  tools  arehiteeture  is  shown  in  Figure  4.  The  designer  using  DYNAMO 


Figure  4:  DYNAMO  Tools  Arehiteeture 


tools  might  begin  with  a  UML  elass  model  drawing  tool  sueh  as  ArgoUML  to  eonstruet  a 
DYNAMO  design.  ArgoUML  is  able  to  export  sueh  designs  using  XMI,  an  industry  standard  XML 
schema  for  UML  CASE  tool  design  descriptions.  We  have  built  a  tool  ealled  ParaGen  for  extraet- 
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ing  design  information  from  an  XMI  file.  Two  versions  were  eonstrueted.  The  first  was  a  stand¬ 
alone  C++  program.  It  made  use  of  the  Xerces  XML  parser  from  Apaehe.  The  second  used  XSLT. 
XSLT  is  a  language  for  manipulating  XML  data.  XSLT  programs  describe  transforms  that  can  be 
applied  to  XML  to  construct  output  files  in  either  XML,  HTML  or  text.  We  used  the  Xalan  tool 
from  IBM  to  process  the  XSLT  transformations.  For  both  the  C++  program  and  the  XSLT  pro¬ 
gram,  we  produced  output  in  a  format  called  Para,  which  is  the  DYNAMO  intermediate  representa¬ 
tion. 

The  intent  of  the  Para  intermediate  representation  is  to  make  it  easy  to  apply  a  variety  of  tools 
to  a  DYNAMO  design.  We  tried  two  specific  applications.  First,  in  order  to  do  static  analysis  of 
UML  designs,  we  applied  the  SMV  model  checker  (from  Carnegie  Mellon  and  Berkeley)  to  them. 
In  this  case,  the  designer  augments  the  class  model  diagram  with  a  statechart  and  generated  XMI 
from  the  diagrams.  Then,  Paragen  is  used  to  convert  the  design  into  Para  format. 

We  built  a  tool  called  Para2SMV  for  converting  designs  in  Para  format  into  the  input  language 
for  SMV.  The  designer  must  add  a  CTL  (Computational  Tree  Logic)  description  of  the  property  to 
be  checked.  Then  SMV  can  be  run  to  see  whether  the  property  holds  for  the  design.  To  support 
this  generation  process,  we  built  a  C++  library,  called  SmvModel.  These  classes  are  used  within 
Para2SMV  to  construct  the  SMV  input  file,  but  they  are  written  in  such  a  way  that  they  can  be 
used  in  any  application  that  needs  to  construct  SMV. 

The  other  tool  that  we  built  was  the  COGITO  mode-component  compiler,  illustrated  in  the 
lower  left  hand  corner  of  Figure  4.  If  the  designer  has  included  OCL  constraints  in  the  UML  class 
model  diagram,  these  will  be  included  in  the  generated  XMI  file  and  conveyed  to  the  Para  repre¬ 
sentation.  COGITO  parses  the  OCL  and  produces  a  parse  tree  internal  representation.  We  have 
constructed  a  C++  library,  similar  to  SmvModel,  called  C++Visitor  that  can  generate  C++ 
mode  component  wrappers  for  components  described  in  the  UML  class  model  diagram.  The 
wrappers,  when  linked  with  the  original  components  maintain  specified  system  invariants,  hence 
providing  assured  behavior. 

The  other  components  in  Figure  4  have  not  been  built.  They  are  shown  in  the  diagram  to  illus¬ 
trate  how  the  tools  architecture  might  be  extended  to  support  other  languages  and  other  static 
checkers. 

Efficient  implementation  of  guaranteed  behavior 

A  wrapper  is  a  code  fragment  that  can  be  used  to  adapt  an  existing  component  for  a  variety  of 
purposes  such  as  providing  a  different  interface  or  enhanced  functionality.  DYNAMO  mode-com¬ 
ponent  wrappers  detect  alterations  to  component  status  and  inform  dependent  components.  If  the 
mode  component  is  itself  dependent  on  other  components,  then  the  wrapper  also  provides  the 
code  that  reestablishes  invariants  to  reflect  the  changes  to  status. 

Mode  component  wrappers  are  implemented  using  several  features  of  the  C++  programming 

language^  One  feature  of  interest  is  operator  overloading.  That  is,  programmers  can  provide  new 
interpretations  for  built-in  C++  operators.  In  the  case  of  DYNAMO,  the  assignment  operator  is 
overloaded.  When  an  assignment  is  made  to  an  element  of  component  status,  a  DYNAMO-gener- 


1.  Details  of  mode  component  implementation  can  be  found  in  reference  [19]. 
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ated  method  is  invoked  that,  besides  performing  the  assignment,  notifies  dependent  components. 
This  additional  ability  is  provided  without  altering  the  source  code  that  performed  the  assignment. 

Alternative  invariant  maintenance  mechanisms 

Besides  mode  components,  we  have  explored  a  variety  of  alternative  mechanisms  for  imple¬ 
menting  invariant  maintenance.  There  are  two  goals  for  this  exploration;  1)  to  apply  DYNAMO 
code  generation  techniques  to  these  mechanisms  and  judge  the  extent  to  which  their  implementa¬ 
tions  can  benefit  from  them;  and  2)  to  better  understand  the  design  space  of  invariant  maintenance 
mechanisms  and,  ultimately,  to  produce  a  policy-based  implementation  [1].  In  the  remainder  of 
this  subsection,  we  present  three  alternative  invariant  maintenance  mechanisms  with  which  we 
have  experimented. 

Encapsulated  collaborations.  To  compare  the  different  invariant  maintenance  strategies,  con¬ 
sider  a  running  example  in  which  three  components,  a,  b,  and  c  collaborate  to  maintain  the 
invariant  a  =  b  +  c. 


Figure  5:  Encapsulated  Invariant  Maintenance 


Figure  5  depicts  a  collaboration  that  maintains  this  invariant  when  the  components  are  assembled 
using  encapsulation.  Notice,  because  a  encapsulates  b  and  c,  all  external  accesses  to  b  and  c 
must  go  through  a.  Moreover,  a  is  responsible  for  maintaining  the  invariant.  Specifically,  when  a 
receives  the  message  setValueOf  B  ( 3 ) ,  it  sends  the  message  setValue  ( 3 )  to  update  the 
value  of  b,  then  retrieves  the  current  value  of  c,  and  sets  its  own  value  to  the  sum.  This  approach 
does  not  require  any  modification  to  the  aggregated  components  (i.e.,  b  and  c),  but  it  requires  sig¬ 
nificant  modification  to  the  aggregator  (a).  In  the  worst  case,  the  interface  of  the  aggregator  could 
swell  to  include  the  union  of  services  over  the  interfaces  of  all  of  the  aggregated  components. 
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Moreover,  every  invocation  of  a  service  that  might  modify  one  of  the  aggregated  components 
incurs  the  cost  of  an  invocation  of  all  of  the  other  aggregated  component  in  order  to  retrieve  val¬ 
ues  necessary  to  re-establish  the  invariant. 

Mediated  collaboration.  Figure  6  depicts  a  collaboration  that  maintains  the  same  invariant 
using  a  mediator. 


Figure  6:  Mediated  Invariant  Maintenance 


In  contrast  to  Figure  5,  collaborating  components  are  peers,  and  each  is  visible  to  other  clients 
who  might  use  its  services.  In  Figure  6,  such  a  client  sends  the  message  setValue  ( 3 )  to  com¬ 
ponent  b.  In  response,  b  sends  the  message  updateOf  B  ( 3 )  to  the  mediator,  which  is  responsi¬ 
ble  for  maintaining  the  invariant.  The  mediator  handles  this  message  by  first  retrieving  the  value 
of  component  c  and  then  setting  the  value  of  component  a  to  be  the  sum.  As  with  encapsulation, 
one  component  (the  mediator)  knows  about  all  of  the  other  components,  but  the  mediator  is  a  new 
component  that  does  nothing  but  maintain  the  invariant.  Consequently,  the  mediator  must  provide 
an  update  operation  for  each  component;  whereas  with  encapsulation,  these  operations  are  part 
of  component  a  (as  is  the  invariant-maintenance  logic).  Also  like  encapsulation,  any  update  of 
any  component  incurs  messages  to  all  of  the  other  components  in  order  to  retrieve  values  needed 
to  reestablish  the  invariant.  Unlike  encapsulation,  each  of  the  components  must  know  about  the 
mediator. 
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Distributed  collaboration.  Figure  7  depicts  a  collaboration  that  maintains  the  same  invariant 
when  the  components  are  assembled  using  a  many-to-many  distributed  collaboration. 


2 ;  modi  f y Va  lueBy  ( -S ) 


Figure  7:  Distributed  Invariant  Maintenance 

In  this  case,  components  b  and  c  contain  direct  references  to  component  a.  Notice,  however,  that 
the  responsibility  for  invariant  maintenance  is  now  distributed  rather  than  localized.  For  example, 
when  b  receives  the  message  setValue(3),  rather  than  announcing  its  new  value  to  a,  it 
announces  the  difference  between  the  new  and  old  values,  and  a's  implementation  of  the  modi- 
f  yValueBy  ( -5 )  message  adds  this  delta  to  its  current  value.  Such  a  distribution  has  the  advan¬ 
tage  of  optimizing  the  number  of  messages,  but  it  does  so  at  the  expense  of  distributing 
knowledge  of  the  invariant  among  the  collaborators. 

Implementation  of  alternative  invariant  maintenance  mechanisms 

The  three  different  composition  strategies  are  supported  by  a  hierarchy  of  classes,  some  of 
which  are  assembly  dependent.  Our  implementation  library  provides  the  following  six  reusable 
classes: 

•  StatusVariable  is  a  parameterized  and  abstract  class  that  generalizes  all  status  variable 
objects  in  a  system.  The  class  provides  a  polymorphic  get  Value  operation  but  no  facility 
for  setting  the  value,  as  some  values  will  be  computed  on  demand  or  set  implicitly. 

•  StatusVariablePrimitive  is  a  parameterized  concrete  class  that  extends  Status- 
Variable  with  an  explicit  setValue  operation. 

•  StatusVariableUpdate  extends  StatusVariablePrimitive  with  facilities  for 
registering  and  announcing  updates  to  one  or  more  listeners.  Objects  of  this  class  respond  to 
setValue  (v)  messages  by  updating  their  value  and  then  sending  the  message 
update  (v,  this )  to  all  registered  listeners,  where  this  is  the  object  that  received  the 
setValue  message. 

•  StatusVariableDelta  extends  StatusVariablePrimitive  with  facilities  for 
registering  and  announcing  changes  (i.e.,  the  difference  between  the  old  and  new  value)  to  one 
or  more  listeners.  Objects  of  this  class  respond  to  setValue  (v)  messages  by  (1)  computing 
the  difference  delta  =  v  -  val  where  val  is  the  old  value,  (2)  setting  val  to  v,  and  (3) 
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sending  the  message  mo  d  i  f  y B  y  ( de  1 1  a ,  this)  to  all  registered  listeners,  where  this  is 
the  object  being  updated. 

•  StatusVariableListener  is  an  interface  class  that  declares  the  update  message. 
Objects  that  implement  this  interface  can  register  as  listeners  to  StatusVariableUpdate 
objects. 

•  StatusVariableDeltaListener  is  an  interface  class  that  declares  the  modif  yBy 
message.  Objects  that  implement  this  interface  can  register  as  listeners  to  StatusVari- 
ableDelta  objects. 

Encapsulated  Invariant  Maintenance.  Figure  8  depicts  the  classes  used  to  implement  encapsu¬ 
lated  collaboration.  Notice  there  is  only  one  assembly-specific  class,  StatusVariableA, 
which  aggregates  two  primitive  status  variables  and  provides  setter  operations  setValueOf  B 
and  setValueOf  C.  Instances  of  StatusVariableA  handle  the  messages  of  the  form  set¬ 
ValueOf  B  ( v)  by  invoking  b  .  setValue  ( v)  and  then  updating  the  local  value  in  accordance 
with  the  invariant.  setValueOf  C  messages  are  handled  similarly.  By  virtue  of  encapsulation, 
clients  can  only  access  instances  of  StatusVariableA. 


Status  Van ^le 
gelValueO  :  T 


I 

1 - 1 

- '  T  ! 

!  7" 

StatusVariableA 

-  b 

*  c 

StatusVariablePrimitive  ~  1 

se1ValueOfB(  T  )  :  void 
setValueOfC(  T  )  :  void 

setValue(  T  )  :  void 

Figure  8:  Implementation  of  Encapsulated  Invariant  Maintenance 


Mediated  Invariant  Maintenance,  Figure  9  depicts  the  classes  used  to  implement  mediated  col¬ 
laboration.  In  this  configuration,  status  variable  a  is  an  instance  of  class  StatusVariableP- 
rimitive.  By  contrast,  b  and  c  are  instances  of  class  StatusVariableUpdate,  which 
means  they  announce  all  updates  to  any  registered  listeners.  The  invariant  is  implemented  by  an 
instance  of  the  (assembly-specific)  class  Mediator.  By  implementing  the  StatusVaria¬ 
bleListener,  instances  of  class  Mediator  can  register  for  and  receive  updates  from  the  b 
and  c  objects.  Notice  also  that  class  Mediator  contains  references  to  each  of  a,  b,  and  c,  which 
allows  it  to  get  and  set  values  as  appropriate  to  maintain  the  invariant.  Moreover,  upon  receiving  a 
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message  of  the  form  update  (v,  o)  ,  a  mediator  ean  compare  o  with  b  and  c  to  decide  which 
object  sent  the  message. 


Status  Variable  Primitive 


t  T 


setValue(  T  )  :  void 
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- - !  ^  ! 

Status  Variable 
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- - !  ~  ' 

Status  Variable  Update  ’jV  listens 

- it - 1 

«in1er1ace» 

Status  Variable  Listener 

update!  StatusVariable*  )  :  void 

Figure  9:  Implementation  of  Mediated  Invariant  Maintenance 


Distributed  Invariant  Maintenance,  Figure  10  depicts  the  classes  used  to  implement  distributed 
collaboration.  In  this  configuration,  the  status  variable  a  is  an  instance  of  an  assembly-specific 
class  StatusVariableA,  which  references  two  status  variables  (b  and  c)  and  implements  the 
StatusVariableDeltaListener  interface  in  order  to  receive  modif  yBy  messages  from 


18 


b 


c 


Status  Variable 


-i  T 


getValueO  :  T 


I 


_  _ !  “T  I 

- - 1  T 

1  *  1 

StatusVariableA  ‘ 

StatusVariablePrimitive 

setValue(  T )  :  void 

7^ 


«inter1ace»  l-T 

Status  VariableDeltaListener 

listens  . 

modify  By  (  T,  SfafusVariaUe* )  :  void 

T  1 


StatusVariableDelta ' 


Figure  10:  Implementation  of  Distributed  Invariant  Maintenanee 


the  objects  that  implement  b  and  c.  Variables  b  and  c  are  instances  of  the  class  StatusVari- 
ableDelta. 
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Future  Work 


CCS  formalization  of  alternative  invariant  maintenance  mechanisms 

A  software  component  defines  services  in  its  interface  and  implements  these  services  by 
requesting  services  from  other  components.  In  addition  to  providing  and  using  services,  an  inter¬ 
active  component  announces  events  to  communicate  changes  in  state  to  interested  observers.  Ser¬ 
vice  requests  and  event  notifications  are  ultimately  realized  by  inter-object  collaborations,  but 
there  are  many  different  ways  to  implement  these  collaborations.  In  a  large  assembly,  the  designer 
should  be  allowed  to  choose  among  different  strategies  in  a  disciplined  manner.  We  designed 
DYNAMO  components  to  be  adaptable  in  this  fashion,  so  that  one  can  make  these  packaging  and 
coordination  decisions  at  assembly  time,  when  one  is  better  able  to  balance  the  costs  and  benefits 
of  these  decisions. 

The  flexibility  afforded  by  this  design  allows  us  to  compose  components  using  a  variety  of 
higher-level'  assembly  operators — such  as  encapsulation,  peer-to-peer  (distributed)  communica¬ 
tion,  and  mediated  communication — and,  in  fact,  we  anticipate  that  designers  will  be  able  to  spec¬ 
ify  assemblies  by  selecting  a  group  of  components,  selecting  an  assembly  strategy,  and  then 
pushing  a  button  to  generate  the  code  that  implements  the  assembly.  To  make  these  ideas  precise, 
we  formalize  DYNAMO  components  and  these  higher-level  operators  by  modeling  them  in  the 
CCS  notation  [14].  In  this  formalization,  DYNAMO  components  are  CCS  agents,  and  the  assembly 
operators  are  idiomatic  combinations  of  CCS  operations  applied  to  these  agents.  Moreover,  we 
define  a  transparent  implementation  of  these  CCS  composition  idioms,  thereby  allowing  an 
assembly  designer  to  manipulate  components  in  a  formal  calculus  and  have  correct  code  gener¬ 
ated  from  these  specifications. 

Finite  differencing  optimizations 

DYNAMO  uses  invariants  to  generate  assembly-specific  code  from  which  to  compose  multiple, 
collaborating  components.  Because  these  invariants  are  not  known  until  assembly  time  (i.e.,  after 
the  design  and  implementation  of  the  individual  components),  this  invariant-maintenance  respon¬ 
sibility  must  be  discharged  by  introducing  new  code  somewhere  in  the  assembly  implementation. 
Often  many  of  the  collaborating  components  must  be  extended,  and  the  nature  of  the  extension 
may  depend  upon  the  particular  invariant.  For  example,  suppose  a  distributed  collaboration  main¬ 
tains  an  attribute  (e.g.,  a)  in  one  component  as  the  sum  of  attributes  (e.g.,  b  and  c)  in  other  com¬ 
ponents.  Then  any  change  to  the  value  of  b  or  c  requires  notifying  a  of  the  change,  and  a  then 
recomputes  the  invariant  expression.  Because  recomputing  the  invariant  expression  may  incur 
multiple  messages  among  these  distributed  components,  we  may  instead  wish  for  b  to  include,  in 
the  notification,  the  difference  between  the  old  and  new  values  for  b.  This  way,  a  can  update  its 
value  without  reevaluating  the  invariant  expression. 

Finite  differencing  is  a  program  optimization  that  systematically  replaces  expensive  computa¬ 
tions  of  an  applicative  expression  E  =  f  (x^ ,  X2 ,  ...  ,  Xj^)  with  an  explicit  variable  that 

maintains  the  value  of  f  and  additional  code  that  updates  the  variable  (without  recomputing  f ) 
when  one  of  the  dependent  variables  (i.e.,  x^,  X2,  ...  ,  Xj^)  changes  [16].  We  borrow  ideas 
from  this  approach  to  generate  invariant-maintenance  code  in  the  components  that  contain  spoil¬ 
ing  attribute  updates  (i.e.,  components  that  update  attributes  that  appear  on  the  right-hand  side  of 
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an  assembly  invariant).  Specifically,  we  use  finite  dilferencing  to  govern  the  generation  of  update 
methods  (e.g.,  the  method  that  updates  the  value  of  a  given  the  change  in  value  of  b)  that  update  a 
dependent  variable  when  one  of  the  independent  variables  is  modified.  Notice  that  if  the  invariant 
expression  E  references  k  different  independent  variables,  then  we  generate  k  different  update 
methods,  each  of  which  re-establishes  the  invariant  in  response  to  a  spoiling  update  of  one  of  the 
k  variables. 

Data  transformers 

In  our  experience  generating  invariant-maintenance  code  from  applicative  invariants,  we 
noticed  that  constraints  over  aggregate  data  types,  such  as  sets  and  sequences,  often  require  the 
use  of  intermediate  state  to  enable  efficient  updates.  Suppose,  for  example,  that  a  viewport  object 
is  used  to  display  a  portion  of  a  sequence  of  text  lines.  Then  some  updates  to  the  sequence  will  not 
cause  any  change  to  the  viewport,  and  it  would  be  nice  to  eliminate  the  generation  of  viewport 
notifications  when  they  will  not  cause  any  change.  A  data  transformer  is  an  object  that  reifies  the 
application  of  a  function  over  an  aggregate  data  type,  such  as  the  derivation  of  a  sub-sequence 
bounded  by  two  indices,  the  selection  of  a  maximal  element,  or  a  reduction  operation  over  all  of 
the  elements  in  a  set  or  sequence.  Data  transformers  compute  and  maintain  these  functions  in  the 
face  of  updates  to  the  subject  collection.  Moreover,  a  data  transformer  can  be  attached  to  a  subject 
collection  in  the  object  that  contains  the  collection,  and  thus  can  be  used  to  minimize  the  number 
of  notifications  required  to  maintain  an  invariant.  Data  transformers  are  reusable  and  are  a  power¬ 
ful  abstraction  for  trading  the  placement  of  computation  in  collaborating  components  so  as  to 
optimize  message  flow. 
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Conclusion 

A  high-assurance  system  behaves  as  you  expeet  it  to  and,  most  importantly,  you  know  that  it 
does  so.  The  enemy  of  assuranee  is  eomplexity,  and  the  main  weapons  in  fighting  eomplexity  are 
abstraetion,  transpareney  and  intentionality.  DYNAMO  uses  model-based  speeifieations  written  in 
OCL  to  express  system  properties  at  a  high  level  of  abstraction.  Wrapper  eode  is  then  generated  in 
sueh  a  way  that  eaeh  of  the  speeified  guarantees  are  mapped  transparently  and  intentionally  into 
self-eontained  elasses  without  compromising  existing  code.  Two  additional  benefits  aeerue  from 
the  DYNAMO  approaeh:  flexibility  and  eeonomy.  The  eode  generation  arehiteeture  and  the  design 
of  the  wrapper  eode  is  sueh  that  the  ehoiee  of  eollaboration  meehanism  ean  be  made  flexibly  at 
assembly  time.  And  the  generated  eode  avoids  mueh  of  the  eostly  indireetion  eommon  in  alterna¬ 
tive  invariant-maintenanee  meehanisms. 

The  DYNAMO  approaeh  is  one  of  invariant  maintenance.  That  is,  system  properties  coneerning 
whieh  assuranee  is  desired  are  expressed  as  assembly  invariants.  An  assembly  invariant  relates 
aspeets  of  one  eomponent  with  those  of  others.  When  the  state  of  the  former  eomponent  ehanges 
in  sueh  a  way  that  the  invariant  aspeet  is  altered,  dependent  eomponents  must  be  notified  and  the 
invariant  reestablished. 

A  variety  of  approaehes  have  been  developed  for  invariant  maintenanee,  and  DYNAMO  intro- 
duees  another,  ealled  a  mode  eomponent.  Mode  eomponents  are  wrapped  eomponents  organized 
into  a  layered,  implieit  invoeation  arehiteeture.  The  wrapping  is  sueh  that  changes  to  the  state  of 
the  underlying  component  are  detected  and  notifieation  made  to  dependent  eomponents  without 
explieit  eoupling  to  those  eomponents. 

The  DYNAMO  projeet  has  also  explored  alternative,  existing  invariant-maintenanee  meeha¬ 
nisms  ineluding  eneapsulated  eomponents,  mediators,  and  distributed,  peer-to-peer  eomponents. 
These  mechanisms,  and  mode  components,  share  enough  strueture  that  common  code-generation 
approaehes  can  be  applied  to  them,  thereby  enabling  assembly-time  configuration.  This  approach 
to  flexible  paekaging  of  eomponents  promotes  reuse. 

DYNAMO  eode  generation  makes  use  of  the  metaprogramming  eapabilities  of  the  C++  lan¬ 
guage  and  eompiler.  Speeifieally,  DYNAMO  expresses  the  various  invariant  maintenanee  meeha¬ 
nisms  as  templates  that  are  proeessed  at  eompile  time,  rather  than  run-time.  Moreover,  the 
templates  are  organized  as  mixin  layers  thereby  redueing  the  need  for  expensive  dynamic  binding. 
The  resulting  eode  provides  a  low-overhead  approaeh  to  solving  the  invariant-maintenanee  prob¬ 
lem. 

The  DYNAMO  projeet  has  been  primarily  eoneerned  with  a  elass  of  system  properties  ealled 
eorreetness  guarantees.  These  guarantees  provide  assuranee  that  the  results  produeed  by  a  system 
are  eorreet.  There  are,  however,  other  types  of  properties  that  must  be  explored.  To  this  end,  we 
have  done  some  investigation  of  synehronization  guarantees  that  determine  whether  a  system  col¬ 
laborates  in  an  intended  fashion.  To  this  must  be  added  work  on  quality-of-serviee  guarantees  that 
deseribes  performance  and  resource-eonsumption  properties  of  assemblies  of  eomponents. 
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Glossary 

•  actor:  A  participant  in  the  environment  is  whieh  an  assembly  lives.  Actors  can  be  passive 
repositories  of  data  or  ean  proaetively  communicate  with  the  assembly. 

•  assembly:  A  eolleetion  of  software  components  that  comprise  a  system. 

•  collaboration:  A  protoeol  of  interaetion  among  multiple  objeets  (called  roles)  to  achieve  some 
purpose  or  goal  or  to  implement  some  invariant. 

•  component:  A  unit  of  software  assembled  with  other  components  to  ereate  a  larger  system. 

•  data  transformer:  An  objeet  that  reifies  the  applieation  of  a  function  over  an  aggregate  data 
type. 

•  distributed  integration:  Invariant  maintenance  aecomplished  by  distributing  responsibility 
amongst  collaborating  components. 

•  encapsulated  integration:  Invariant  maintenance  provided  by  a  single  encompassing  compo¬ 
nent  that  aggregates  the  other  collaborating  components. 

•  event:  An  atomic  unit  of  communications,  which  may  carry  data. 

•  explicit  invocation:  A  collaboration  mechanism  in  which  (in  an  00  implementation)  an  inte¬ 
grand  stores  referenees  to  other  integrands  and  directly  invokes  operations  through  these  ref¬ 
erences. 

•  finite  dijferencing:  A  program  optimization  that  systematically  replaces  expensive  computa¬ 
tions  of  an  applicative  expression  with  an  explieit  variable  that  maintains  the  value  of  the 
expression  and  additional  code  that  updates  the  variable  (without  recomputing  the  expression) 
when  one  of  the  dependent  variables  ehanges. 

•  flexibility:  The  property  of  a  system  or  component  that  refieets  the  extent  to  whieh  the  system 
or  component  can  be  used  in  a  variety  of  configurations. 

•  flexible  packaging:  A  design  strategy  in  whieh  the  ehoiee  of  component  eollaboration  mecha¬ 
nism  is  delayed  until  assembly  time. 

•  guarantee:  A  description  of  expected  assembly  behavior. 

•  implicit  invocation:  An  arehiteetural  style  in  whieh  components  whose  status  change  notify 
dependent  components  that  have  expressed  their  interest.  The  notifying  component  is  not 
explicitly  aware  of  the  identity  of  the  notified  eomponent. 

•  integrand:  a  eomponent  of  a  collaboration. 

•  intentionality:  The  property  of  a  feature  that  reflects  the  extent  to  which  the  correetness  of  the 
feature  is  readily  apparent  from  the  implementation  of  a  system  ineorporating  it. 

•  invariant:  A  property  of  an  assembly  or  a  component  that  holds  between  event  oecurrences. 
Invariants  are  expressed  in  terms  of  relationships  among  the  assembly's  pereepts  or  status 
variables. 

•  invariant  maintenance:  The  process  by  which  a  system  responds  to  a  change  in  one  compo¬ 
nent  in  order  to  reestablish  its  invariants. 

•  mediated  integration:  Invariant  maintenance  provided  by  a  mediator. 
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•  mediator:  A  software  component  that  reifies  integration  relationships  into  a  component  differ¬ 
ent  from  the  components  being  integrated. 

•  metaprogramming:  An  implementation  technique  for  specifying  software  properties  to  a  com¬ 
piler  and  allowing  it  to  generate  source  code  rather  than  coding  the  properties  directly. 

•  mixin  class:  Class  templates  in  which  the  template  parameter  is  used  to  define  the  base  class 
from  which  the  (instantiated)  mixin  class  derives. 

•  mixin  layer:  A  collaboration  implemented  by  a  template  class  with  one  or  more  nested  classes, 
each  of  which  is  a  mixin  class  that  defines  a  different  role  in  the  collaboration. 

•  mode  component:  A  hierarchical  software  component  whose  interface  provides  a  continu¬ 
ously  updated  view  of  its  current  status. 

•  mode  component  architecture:  A  layered,  implicit-invocation  architecture  where  all  associ¬ 
ated  components  are  mode  components. 

•  mode  component  constraint:  A  single-assignment  OCL  expression  where  the  left-hand  side 
contains  a  single  status  variable  and  the  right  hand  side  is  a  formula  dependent  upon  status 
variables  of  mode  components  in  an  adjacent  layer. 

•  OCL:  The  Object  Constraint  Language.  A  notation  for  expressing  invariants  and  pre  and  post 
condition  information  in  UML  diagrams. 

•  OCL  constraint:  An  OCL  expression  attached  to  either  a  UML  class  or  an  association. 

•  overhead:  The  property  of  a  feature  that  reflects  the  performance  penalty  paid  by  a  system 
when  the  feature  is  added. 

•  packaging:  The  replacement  of  abstract  communication  primitives  in  a  component's  source 
code  with  actual  code  that  implements  the  primitives. 

•  percept:  Visual  feedback;  generally  an  attribute  of  the  assembly  that  is  visible  to  the  user. 

•  pre/post  conditions:  A  specific  type  of  OCL  expressions  that  specify  the  behavior  of  compo¬ 
nent  services. 

•  response:  A  property  of  an  assembly  or  a  component  that  holds  as  the  result  of  the  assembly 
or  component  processing  an  event.  Responses  are  expressed  in  terms  of  relationships  among 
the  elements  of  the  assembly's  or  component's  state. 

•  role:  A  fragment  that  comprises  the  subset  of  an  actual  object’s  characteristics  that  are 
required  for  the  object  to  participate  in  a  particular  collaboration. 

•  service:  An  explicitly  invoked  operation  used  by  a  component  in  an  adjacent  layer  to  alter  a 
componenfs  state. 

•  status:  That  part  of  a  component’s  state  that  is  visible  to  other  components. 

•  status  variable:  A  component  attribute  that  provides  automatic  notification  when  its  state 
changes  to  client  components  in  an  adjacent  layer. 

•  transparency:  The  property  of  a  feature  of  a  system  or  component  that  reflects  the  extent  the 
feature  can  be  added  to  the  system  or  component  without  requiring  alterations  to  them. 

•  wrapper:  A  code  fragment  that  can  be  used  to  adapt  an  existing  component  for  a  variety  of 
purposes  such  as  providing  a  different  interface  or  enhancing  functionality. 
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